SUID Disabler and Permission Hardener
Attack surface reduction via disabling of SUID-enabled binaries.
Introduction[edit]
SUID Disabler and Permission Hardener aims to increase the security of the system by improving Strong Linux User Account Isolation, setting more restrictive file permissions and reducing attack surface through disabling of SUID-enabled binaries. [1] This feature is enabled by default and part of security-misc.
SUID vs. SGID[edit]
SUID (Set owner User ID up on execution) is: [2]
... a special type of file permissions given to a file. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SUID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file owner rather that the user who runs it. In simple words users will get file owner’s permissions as well as owner UID and GID when executing a file/program/command.
In simple terms, SUID (or setuid) allows a user to execute a binary with the privileges of the binary's owner. This is often used to allow unprivileged users to utilize certain functionality that is normally only reserved for the root user. As such, many SUID binaries have a history of privilege escalation security vulnerabilities.
Quote Removing SUID and SGID flags off binaries:
SUID and SGID binaries pose a risk of exploitation due to them running as user 'root' or as group 'root' (or some other group or user).
A related Linux functionality is SGID (Set Group ID up on execution). This is: [3]
... a special type of file permissions given to a file/folder. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SGID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file group permissions to become member of that group to execute the file. In simple words users will get file Group’s permissions when executing a Folder/file/program/command. SGID is similar to SUID. The difference between both is that SUID assumes owner of the file permissions and SGID assumes group’s permissions when executing a file instead of logged in user inherit permissions.
This page sometimes only refers to SUID while it means both, SUID and SGID. Even the name of the program -- SUID Disabler and Permission Hardener -- leaves out SGID, even though SGID disabling is included.
Disabled Binaries and Libraries[edit]
SUID Disabler and Permission Hardener configuration folders are /etc/permission-hardener.d
and /usr/local/etc/permission-hardener.d
. (SUID Disabler and Permission Hardener default configuration folder)
SUID Disabler and Permission Hardener searches the following folders for SUID/SGID binaries/libraries and disables all except those which are whitelisted in the configuration file. The following list of folders were copied from the default configuration file at the time of writing.
## Remove all SUID/SGID binaries/libraries. /opt/ nosuid /usr/bin/ nosuid /usr/lib32/ nosuid /usr/lib64/ nosuid /usr/lib/ nosuid /usr/local/bin/ nosuid /usr/local/lib32/ nosuid /usr/local/lib64/ nosuid /usr/local/lib/ nosuid /usr/local/opt/ nosuid /usr/local/sbin/ nosuid /usr/local/usr/bin/ nosuid /usr/local/usr/lib32/ nosuid /usr/local/usr/lib64/ nosuid /usr/local/usr/lib/ nosuid /usr/local/usr/sbin/ nosuid /usr/sbin/ nosuid
(Missing folders? No, because of UsrMerge.)
It does not search the whole hard drive because:
- No known Debian packages or other software following the file hierarchy standard installs SUID/SGID binaries/libraries into other disk locations. Since installation of new malicious root owned SUID/SGID binaries/libraries would require root, this is outside of the threat model. An attacker capable of creating malicious root owned SUID/SGID binaries/libraries in non-standard disk locations already owns the system. The purpose of SUID Disabler is to avoid malicious/compromised non-root accounts from escalating to root using SUID, not to control what an attacker with root can do. For that, see Untrusted Root - improve Security by Restricting Root,
apparmor.d
(Full System AppArmor Profile) and Multiple Boot Modes for Better Security - a Design for the Implementation of Untrusted Root. - It does not search
/mnt
or/media
because another Linux installation could be mounted in that folder which should not be broken by SUID Disabler. [4] - It does not search folders
/root
because no SUID binaries should be there by default. That folder is by default readable only byroot
. Ifroot
was to create a custom SUID and move it there, thenroot
should be able to execute it. - It searches folders
/opt
or/usr/local/opt
by default (version19.7-1
and above). These folders do not exist in a default installation. Rationale for that is that some manually installed software installs itself there. Some lesser important functionality might require SUID/SGID. The SUID/SGID bit might have been accidentally set by a developer. (Or part of legacy install scripts. Useful in past, then forgotten, now obsolete.) Removal of SUID/SGID might in many cases go unnoticed by the user. I.e. user might not notice any broken functionality. For example, cases where that software is run as root anyhow. [5] - This process is re-done every time SUID Disabler and Permission Hardener is run when security-misc is installed or updated.
- Searching the whole disk at every boot would slow down the boot process.
- Another feature by security-misc, Enhanced Security via Mount Options and Compiler Restrictions will in future re-mount folders such as
/home
with mount optionsnoexec
andnoexec
at early boot time anyhow. This is a better solution. Therefore there is no need to duplicate that functionality in SUID Disabler.
Some SUID/SGID binaries such as sudo
whitelisted by default because otherwise a Linux desktop computer would be unusable. The choice of whitelisted SUID/SGID binaries is justified in SUID Disabler and Permission Hardener default configuration folder and in its development discussion.
It would however in theory be desirable to have a system fully free of SUID/SGID binaries for general and kernel related attack surface reduction. [6] Quote security researcher Solar Designer:
Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)
Operating such a system might however be impractical and at odds with other security advice. One would have to operate without both, sudo
and su
, would have to ignore advice to not login as root as explained on the Safely Use Root Commands wiki page. Therefore such a configuration is still undocumented. To aid such experiments, research, developers and advanced users, SUID Disabler and Permission Hardener has an optional feature to Disable All SUID Binaries.
Implementation:
/usr/bin/permission-hardener
.- Strictly optional systemd unit file to run at boot time which is not important because permission hardener runs every time any package is installed or upgraded using APT.
Enable SUID Disabler and Permission Hardener[edit]
Manual Start of Permission Hardener[edit]
Optional. This is useful to better understand what SUID Disabler and Permission Hardener is actually doing after expanding its configuration folder.
sudo permission-hardener
(The printout will look similar to this.)
Optional At Boot Time[edit]
Optional. Strictly optional systemd unit to run at boot time which is not important because permission hardener runs every time any package is installed or upgraded using APT.
1. Enable and start systemd unit.
sudo systemctl enable --now permission-hardener.service
2. Done.
Permission hardener will now run also at boot time in addition to when APT installs or upgrades packages.
SUID Disabler and Permission Hardener Operations[edit]
Show dpkg-statoverride List[edit]
SUID Disabler is based on the standard Debian tool dpkg-statoverride
(man page). It is a tool to reliably override ownership and mode of files.
SUID Disabler would be incomplete if it did not use dpkg-statoverride
. This is because when a package is upgraded or re-installed, dpkg
would reset the original file permissions. I.e. re-enable SUID. To prevent a race condition (malware abusing SUID before SUID can re-disable), dpkg-statoverride
is being used.
It might be helpful to view the list of overwritten dpkg file permissions.
dpkg-statoverride --list
Note that even when not using SUID Disabler at all, Debian (and a few other packages) by default adds a few dpkg statoverwrites by themselves. Not all entries in the list of dpkg statoverwrites are the caused by SUID Disabler. Therefore SUID Disabler maintains its own lists of changes. It records permissions before it applies any changes as well as records the new permissions set by SUID Disabler. In case of any issues it might however be useful to check the list of file permission changes enforced by dpkg-statoverride
.
View List of Debian Default File Permissions Before Changes[edit]
File /var/lib/permission-hardener/existing_mode/statoverride
records modes before changing them using SUID Disabler and Permission Hardener. To view, run the following command.
cat /var/lib/permission-hardener/existing_mode/statoverride
View List of Changed Mode Permissions[edit]
File /var/lib/permission-hardener/new_mode/statoverride
records modes that were changed by SUID Disabler and Permission Hardener. To view, run the following command.
cat /var/lib/permission-hardener/new_mode/statoverride
Alternatively see dpkg-statoverride list.
Compare Mode Changes[edit]
To view previous modes and how these were changed (replace meld
with your favorite diff
viewer):
meld /var/lib/permission-hardener/existing_mode/statoverride /var/lib/permission-hardener/new_mode/statoverride
Re-enable Specific SUID Binaries[edit]
Re-enable specific SUID binaries means to restore their SUID bit.
Syntax:
Note: Full path to the file is required.
sudo permission-hardener disable /full/path/to/file
Example:
Note: Replace /usr/sbin/exim4
with the actual full path to the binary.
sudo permission-hardener disable /usr/sbin/exim4
What permission-hardener's disable
option does is restoring the binary's original file permissions.
This is only effective until new packages are installed or upgraded using APT. To make the change permanent, the SUID binary needs to be whitelisted as per wiki chapter Whitelist Specific SUID Binaries.
Security Impact of Disabling Permission Hardening[edit]
What is the security impact of disabling permission hardening for a SUID binary?
Generally, either if the user wishes to use some specific functionality, it might be required to soften some security hardening. This always results in some additional attack surface. Either soften the hardening and use the functionality, or abstain from using the functionality. There is no other choice. Undoing permission hardening for a specific SUID binary increases the attack surface. It does not result in automatic system compromise. Hardening is an additional precaution. The absence of hardening is non-ideal, but most activities in life require a balance of functionality versus security.
The specific security impact of enabling a SUID binary is hard to quantify. The most the user can do is to search using search engines for past vulnerabilities of the specific SUID binary compared with a baseline SUID for comparison purposes.
Whitelist Specific SUID Binaries[edit]
1. Create settings folder.
sudo mkdir -p /etc/permission-hardener.d
2. Open file /etc/permission-hardener.d/20_user.conf
in an editor with root rights.
Kicksecure
See
Open File with Root Rights
for detailed instructions on why to use sudoedit
for better security and how to use it.
sudoedit /etc/permission-hardener.d/20_user.conf
Kicksecure for Qubes
NOTES:
- When using Kicksecure-Qubes, this needs to be done inside the Template.
sudoedit /etc/permission-hardener.d/20_user.conf
- After applying this change, shutdown the Template.
- All App Qubes based on the Template need to be restarted if they were already running.
- This is a general procedure required for Qubes and unspecific to Kicksecure for Qubes.
Others and Alternatives
- This is just an example. Other tools could achieve the same goal.
- If this example does not work for you or if you are not using Kicksecure, please refer to this link.
sudoedit /etc/permission-hardener.d/20_user.conf
3. Learn the syntax.
Do not add this.
/full/path/to/file exactwhitelist
4. Add.
Example. Replace /usr/sbin/exim4
with the actual path to the binary intended to be whitelisted.
/usr/sbin/exim4 exactwhitelist
5. Save.
6. Re-enable SUID binary.
Steps in this chapter by itself are not sufficient. It is required to re-enable the specific SUID binary as per above chapter.
7. Done.
Steps to whitelist SUID binary are complete.
Whitelist Specific Capability Binaries[edit]
1. Follow the same instructions as in above chapter Whitelist Specific SUID Binaries even though this is a capability binary and not a SUID binary.
2. Learn the syntax.
Do not run this command.
sudo setcap capability /full/path/to/binary
3. Re-add previously removed capability.
The following example adds capability cap_net_raw+ep
to binary /bin/ping
. Replace cap_net_raw+ep
with the actual capability and binary /bin/ping
with the actual binary intended to be re-added.
sudo setcap cap_net_raw+ep /bin/ping
4. Verify capability was re-added.
Syntax.
sudo getcap /full/path/to/binary
Example.
sudo getcap /bin/ping
Should show.
/bin/ping = cap_net_raw+ep
5. Done.
Disable All SUID Binaries[edit]
whitelists_disable_all=true
Disable SUID Disabler and Permission Hardener[edit]
Undo all changes. The following command is is only efficient until upgrade of package security-misc or reboot. To disable permanently the subsequent systemctl
commands are required as well.
sudo permission-hardener disable all
Disable and stop systemd unit.
sudo systemctl disable --now permission-hardener.service
Mask systemd unit.
sudo systemctl mask permission-hardener.service
SUID SGID Hardening Issues[edit]
This is a list of SUID/SGID programs which have their set-user-id
bit and/or set-group-id
bit removed.
To use the following programs you need to:
- either use root rights, OR
- restore SUID/SGID (undocumented)
Standard GNU/Linux utilities:
- These tools probably are used much nowadays on Linux desktop single user computers. If you need any of this, you are better off using root.
passwd
man (change user password)chage
man (change user password expiry information)expiry
man (check and enforce password expiration policy)chfn
man (change real user name and information)chsh
man (change login shell)gpasswd
man (administer/etc/group
and/etc/gshadow
)newgrp
man (log in to a new group)
applications related:
/usr/lib/kde4/libexec/fileshareset
: thunar/usr/lib/openssh/ssh-keysign
ssh-agent
pppd
man (Point-to-Point Protocol Daemon) Dial up modem only?
root rights related:
su
: substitute user. See also documentation aboutsu
pkexec
some issues unrelated to SUID/usr/lib/kde4/libexec/kdesud
mount related:
mount
umount
mount.nfs
mount.cifs
ntfs-3g
/usr/lib/eject/dmcrypt-get-device
virtualization related:
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
(Manage nics in another network namespace) Does Anbox need this?
namespace related:
newgidmap
man (set the gid mapping of a user namespace)newuidmap
man (set the uid mapping of a user namespace)
crontab related:
- You are better off editing any non-root user's crontab with root rights.
crontab
man (Manage users crontab files)at
man (executes commands at a specified time)
local mail, mailspool, printing related:
- Related to local mail, mailspool. Webmail and e-mail clients should be fine. These tools probably are used much nowadays on Linux desktop single user computers.
dotlockfile
man (Utility to manage lockfiles)dotlock.mailutils
man (lock mail spool files) Also related to printing?exim4
man (Mail Transfer Agent)/usr/lib/evolution/camel-lock-helper-1.2
See this.
system local messaging:
- Even more obscure than above. Linux multi user systems could send each other local messages.
wall
man (write a message to all users)write
/bsd-write
man (send a message to another user)
Network Information Server
(NIS
):
unix_chkpwd
man (Helper binary that verifies the password of the current user) Related toNetwork Information Server
(NIS
)? See this discussion. Does not look important.
passwd[edit]
passwd
needs to be started as root / with sudo.
sudo passwd user
See also: change password
Related: root
SUID SGID Troubleshooting[edit]
Syntax:
stat -c "%n %a %U %G" /path/to/filename
Example:
stat -c "%n %a %U %G" /usr/bin/sudo
Expected output.
/usr/bin/sudo 4755 root root
SUID Disabler and Permission Hardener Design[edit]
- Some binaries like
su
when SUID removed will pretend to work but then always give a permission denied error. Therefore, SUID Disabler and Permission Hardener will remove SUID (s
) / SGID (g
) and execute permissionx
for 'group' (g
) and 'others' (o
). Similar tochmod og-sgx /path/to/filename
. Removing execution permission is useful to make binaries such assu
fail closed rather than fail open if SUID was removed from these. It does not remove SUID/SGID and execute permissions for 'owner' (u
). It does not run similar to.chmod u-sgx /path/to/filename
- SUID Disabler and Permission Hardener does not remove read access since there is no security benefit and it is easier to manually undo. Preventing read access to a binary can prevent an attacker from reverse engineering it and discovering vulnerabilities to exploit however the attacker could also simply read the source code of the binary since Kicksecure is comprised of Freedom Software. Even ignoring that, there are still ways to leak the contents of unreadable binaries. [7] Thus, this would be an incomplete and easily circumvented form of security through obscurity.
- Are there SUID or SGID binaries which are still useful if executable by anyone if SUID/SGID has been removed from these? Yes. For example, the
mount
command.
- Are there SUID or SGID binaries which are still useful if executable by non-root users if SUID/SGID has been removed from these? Yes. For example, the
mount
command.
SUID Disabler and Permission Hardener Printout[edit]
This printout was added in November 2020. It might not be kept up to date. It is for illustrative purposes to document what SUID Disabler and Permission Hardener is actually doing.
When initially running SUID Disabler and Permission Hardener for the first time.
sudo permission-hardener
The printout will look like the following.
INFO: START parsing config_file: '/etc/permission-hardener.d/30_default.conf' run: dpkg-statoverride --add --update root root 745 /bin/mount run: dpkg-statoverride --add --update root root 745 /usr/bin/mount run: dpkg-statoverride --add --update root root 0755 /home run: dpkg-statoverride --add --update user user 0700 /home/user run: dpkg-statoverride --add --update root root 0700 /root run: dpkg-statoverride --add --update root root 0700 /boot run: dpkg-statoverride --add --update root root 0600 /etc/permission-hardener.d INFO: fso: '/usr/local/etc/permission-hardener.d' - does not exist. This is likely normal. run: dpkg-statoverride --add --update root root 0700 /lib/modules INFO: set-group-id found - file_name: '/bin/expiry' | existing_mode: '2755' | new_mode: '744' run: dpkg-statoverride --add --update root shadow 744 /bin/expiry INFO: set-user-id found - file_name: '/bin/chfn' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/chfn INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/bin/fusermount' | existing_mode: '4755' | matchwhite_list_entry: '/fusermount' INFO: set-group-id found - file_name: '/bin/bsd-write' | existing_mode: '2755' | new_mode: '744' run: dpkg-statoverride --add --update root tty 744 /bin/bsd-write INFO: set-user-id found - file_name: '/bin/umount' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/umount INFO: set-user-id found - file_name: '/bin/gpasswd' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/gpasswd INFO: set-user-id found - file_name: '/bin/newgrp' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/newgrp INFO: SKIP whitelisted - set-user-id found - file_name: '/bin/bwrap' | existing_mode: '4755' INFO: set-group-id found - file_name: '/bin/chage' | existing_mode: '2755' | new_mode: '744' run: dpkg-statoverride --add --update root shadow 744 /bin/chage INFO: set-user-id found - file_name: '/bin/su' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/su INFO: set-user-id found - file_name: '/bin/pkexec' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/pkexec INFO: SKIP whitelisted - set-user-id found - file_name: '/bin/sudo' | existing_mode: '4755' INFO: set-user-id found - file_name: '/bin/passwd' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/passwd INFO: set-group-id found - file_name: '/bin/wall' | existing_mode: '2755' | new_mode: '744' run: dpkg-statoverride --add --update root tty 744 /bin/wall INFO: set-group-id found - file_name: '/bin/crontab' | existing_mode: '2755' | new_mode: '744' run: dpkg-statoverride --add --update root crontab 744 /bin/crontab INFO: set-user-id found - file_name: '/bin/chsh' | existing_mode: '4755' | new_mode: '744' run: dpkg-statoverride --add --update root root 744 /bin/chsh INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/bin/fusermount' | existing_mode: '4755' | matchwhite_list_entry: '/fusermount' INFO: SKIP whitelisted - set-user-id found - file_name: '/usr/bin/bwrap' | existing_mode: '4755' INFO: SKIP whitelisted - set-user-id found - file_name: '/usr/bin/sudo' | existing_mode: '4755' INFO: set-group-id found - file_name: '/sbin/unix_chkpwd' | existing_mode: '2755' | new_mode: '744' run: dpkg-statoverride --add --update root shadow 744 /sbin/unix_chkpwd INFO: SKIP matchwhitelisted - set-group-id found - file_name: '/lib/x86_64-linux-gnu/utempter/utempter' | existing_mode: '2755' | matchwhite_list_entry: '/utempter/utempter' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/lib/dbus-1.0/dbus-daemon-launch-helper' | existing_mode: '4754' | matchwhite_list_entry: 'dbus-daemon-launch-helper' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/lib/qubes/qfile-unpacker' | existing_mode: '4755' | matchwhite_list_entry: '/qubes/qfile-unpacker' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/lib/policykit-1/polkit-agent-helper-1' | existing_mode: '4755' | matchwhite_list_entry: 'polkit-agent-helper-1' INFO: SKIP matchwhitelisted - set-group-id found - file_name: '/usr/lib/x86_64-linux-gnu/utempter/utempter' | existing_mode: '2755' | matchwhite_list_entry: '/utempter/utempter' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/lib/dbus-1.0/dbus-daemon-launch-helper' | existing_mode: '4754' | matchwhite_list_entry: 'dbus-daemon-launch-helper' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/lib/qubes/qfile-unpacker' | existing_mode: '4755' | matchwhite_list_entry: '/qubes/qfile-unpacker' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/lib/policykit-1/polkit-agent-helper-1' | existing_mode: '4755' | matchwhite_list_entry: 'polkit-agent-helper-1' INFO: fso: '/usr/local/lib32/' - does not exist. This is likely normal. INFO: fso: '/usr/local/lib64/' - does not exist. This is likely normal. INFO: END parsing config_file: '/etc/permission-hardener.d/30_default.conf' INFO: START parsing config_file: '/etc/permission-hardener.d/30_ping.conf' run: dpkg-statoverride --add --update root root 0755 /bin/ping run: setcap -r /bin/ping INFO: END parsing config_file: '/etc/permission-hardener.d/30_ping.conf'
SUID Disabler and Permission Hardener Log Analysis[edit]
Applied Permission Changes[edit]
Permission Hardening[edit]
run: dpkg-statoverride --add --update root root 0755 /home run: dpkg-statoverride --add --update user user 0700 /home/user run: dpkg-statoverride --add --update root root 0700 /root run: dpkg-statoverride --add --update root root 0700 /boot run: dpkg-statoverride --add --update root root 0600 /etc/permission-hardener.d run: dpkg-statoverride --add --update root root 0700 /lib/modules
SUID Disabling[edit]
run: dpkg-statoverride --add --update root root 745 /bin/mount run: dpkg-statoverride --add --update root root 745 /usr/bin/mount run: dpkg-statoverride --add --update root shadow 744 /bin/expiry run: dpkg-statoverride --add --update root root 744 /bin/chfn run: dpkg-statoverride --add --update root tty 744 /bin/bsd-write run: dpkg-statoverride --add --update root root 744 /bin/umount run: dpkg-statoverride --add --update root root 744 /bin/gpasswd run: dpkg-statoverride --add --update root root 744 /bin/newgrp run: dpkg-statoverride --add --update root shadow 744 /bin/chage run: dpkg-statoverride --add --update root root 744 /bin/su run: dpkg-statoverride --add --update root root 744 /bin/pkexec run: dpkg-statoverride --add --update root root 744 /bin/passwd run: dpkg-statoverride --add --update root tty 744 /bin/wall run: dpkg-statoverride --add --update root crontab 744 /bin/crontab run: dpkg-statoverride --add --update root root 744 /bin/chsh run: dpkg-statoverride --add --update root shadow 744 /sbin/unix_chkpwd run: dpkg-statoverride --add --update root root 0755 /bin/ping
Capability Removal[edit]
run: setcap -r /bin/ping
Parsed Configuration Files[edit]
INFO: START parsing config_file: '/etc/permission-hardener.d/30_default.conf' INFO: END parsing config_file: '/etc/permission-hardener.d/30_default.conf' INFO: START parsing config_file: '/etc/permission-hardener.d/30_ping.conf' INFO: END parsing config_file: '/etc/permission-hardener.d/30_ping.conf'
Whitelisted SUID Binaries[edit]
INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/bin/fusermount' | existing_mode: '4755' | matchwhite_list_entry: '/fusermount' INFO: SKIP whitelisted - set-user-id found - file_name: '/bin/bwrap' | existing_mode: '4755' INFO: SKIP whitelisted - set-user-id found - file_name: '/bin/sudo' | existing_mode: '4755' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/bin/fusermount' | existing_mode: '4755' | matchwhite_list_entry: '/fusermount' INFO: SKIP whitelisted - set-user-id found - file_name: '/usr/bin/bwrap' | existing_mode: '4755' INFO: SKIP whitelisted - set-user-id found - file_name: '/usr/bin/sudo' | existing_mode: '4755' INFO: SKIP matchwhitelisted - set-group-id found - file_name: '/lib/x86_64-linux-gnu/utempter/utempter' | existing_mode: '2755' | matchwhite_list_entry: '/utempter/utempter' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/lib/dbus-1.0/dbus-daemon-launch-helper' | existing_mode: '4754' | matchwhite_list_entry: 'dbus-daemon-launch-helper' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/lib/qubes/qfile-unpacker' | existing_mode: '4755' | matchwhite_list_entry: '/qubes/qfile-unpacker' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/lib/policykit-1/polkit-agent-helper-1' | existing_mode: '4755' | matchwhite_list_entry: 'polkit-agent-helper-1' INFO: SKIP matchwhitelisted - set-group-id found - file_name: '/usr/lib/x86_64-linux-gnu/utempter/utempter' | existing_mode: '2755' | matchwhite_list_entry: '/utempter/utempter' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/lib/dbus-1.0/dbus-daemon-launch-helper' | existing_mode: '4754' | matchwhite_list_entry: 'dbus-daemon-launch-helper' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/lib/qubes/qfile-unpacker' | existing_mode: '4755' | matchwhite_list_entry: '/qubes/qfile-unpacker' INFO: SKIP matchwhitelisted - set-user-id found - file_name: '/usr/lib/policykit-1/polkit-agent-helper-1' | existing_mode: '4755' | matchwhite_list_entry: 'polkit-agent-helper-1'
Non-Existing Folders[edit]
INFO: fso: '/usr/local/etc/permission-hardener.d' - does not exist. This is likely normal. INFO: fso: '/usr/local/lib32/' - does not exist. This is likely normal. INFO: fso: '/usr/local/lib64/' - does not exist. This is likely normal.
Permission Hardener Issues[edit]
The following folders are only readable with root rights.
/boot
- Issue: Breaks KVM direct kernel boot using kernel images located in
/boot
. I.e. when using KVM to boot a kernel from the host disk located in folder/boot
will not be possible by default. The safest alternative would be using another file location for kernel images or inside VM kernel images.
- Issue: Breaks KVM direct kernel boot using kernel images located in
Search for SUID SGID[edit]
After enabling SUID Disabler and Permission Hardener.
Search for SUID binaries.
sudo find / -perm -4000 -type f -executable
Ignore the following.
find: ‘/proc/5422/task/5422/fd/6’: No such file or directory find: ‘/proc/5422/task/5422/fdinfo/6’: No such file or directory find: ‘/proc/5422/fd/5’: No such file or directory find: ‘/proc/5422/fdinfo/5’: No such file or directory
The following list shows only white listed SUID binaries.
/usr/lib/dbus-1.0/dbus-daemon-launch-helper /usr/lib/qubes/qfile-unpacker /usr/lib/policykit-1/polkit-agent-helper-1 /usr/bin/fusermount /usr/bin/bwrap /usr/bin/sudo
Search for SGID binaries.
sudo find / -perm -2000 -type f -executable
The following list shows only white listed SGID binaries.
/usr/lib/x86_64-linux-gnu/utempter/utempter
Debugging[edit]
Look what SUID Disabler and Permission Hardener is actually doing. Most interesting to run this command during initial enabling of SUID Disabler and Permission Hardener.
sudo journalctl --no-pager -b -o cat -u permission-hardener
Future Work[edit]
- Add a scan script for scanning folders where SUID binaries commonly reside. Option to scan whole disk.
- Add an APT hook to scan folders where SUID binaries commonly reside to scan after package installation and notify user when new SUID where installed.
https://github.com/openSUSE/permissions/tree/master/profiles
References[edit]
- ↑ Discovering a Local SUID Exploit
- ↑ https://web.archive.org/web/20211101172007/https://www.linuxnix.com/suid-set-suid-linuxunix/
- ↑ https://web.archive.org/web/20170522054219/https://www.linuxnix.com/sgid-set-sgid-linuxunix/
- ↑ https://forums.whonix.org/t/suid-disabler-and-permission-hardener/7706/70
- ↑ https://forums.whonix.org/t/suid-disabler-and-permission-hardener/7706/68
- ↑ https://forums.whonix.org/t/suid-disabler-and-permission-hardener/7706/65
- ↑ https://forums.grsecurity.net/viewtopic.php?t=2939
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!